Contact centers, such as Automatic Call Distribution or ACD systems, are employed by many enterprises to service customer contacts. A typical contact center includes a switch and/or server to receive and route incoming packet-switched and/or circuit-switched contacts and one or more resources, such as human agents and automated resources (e.g., Interactive Voice Response (IVR) units), to service the incoming contacts. Contact centers distribute contacts, whether inbound or outbound, for servicing to any suitable resource according to predefined criteria. In many existing systems, the criteria for servicing the contact from the moment that the contact center becomes aware of the contact until the contact is connected to an agent are customer-specifiable (i.e., programmable by the operator of the contact center), via a capability called vectoring. Normally in present-day ACDs when the ACD system's controller detects that an agent has become available to handle a contact, the controller identifies all predefined contact-handling skills of the agent (usually in some order of priority) and delivers to the agent the highest-priority oldest contact that matches the agent's highest-priority skill.
The primary objective of contact center management, including call-distribution algorithms, is to ultimately maximize contact center performance and profitability. An ongoing challenge in contact center administration is monitoring of selected data entities associated with contact center operation to optimize the use of contact center resources and maximize agent performance and profitably. Current products for monitoring and reporting on contact center performance, such as Call Management System or CMS™ and Avaya IQ™ by Avaya, Inc., are configured as data warehouses that extract data from multiple sources, transform the data into a normalized form, and load the data into the data warehouse database, typically on a real time basis.
A common type of data warehouse is based on dimensional modeling. Dimensional modeling is a data model that divides the world into measurements and context. Measurements are usually numeric and taken repeatedly. Numeric measurements are facts. Facts are surrounded by textual context in existence when the fact is recorded. Context is often subdivided into dimensions. Fact tables are used in dimensional modeling to logically model measurements with multiple foreign keys referring to the contextual entities. The contextual entities each have an associated primary key. A “key” is a data element (e.g., attribute or column) that identifies an instance of an entity or record in a collection of data, such as a table. A “primary key” is a column or combination of columns whose values uniquely identify a row in a table or is the attribute or group of attributes selected from the candidate keys as the most suitable to uniquely identify each instance of an entity. A “foreign key” refers to a column or combination of columns whose values are required to match a primary key in another table or is a primary key of a parent entity that contributes to a child entity across a relationship. Types of primary keys include a natural key, or a key having a meaning to users, and a surrogate key, or a key that is artificially or synthetically established, meaningless to users, and used as a substitute for a natural key.
If the same entity (e.g., agent) is represented on multiple data sources (e.g., inbound call system and outbound call system) by different natural keys, a traditional data warehouse generates and assigns a surrogate key to identify the entity. The surrogate key is an internal identifier managed by the data warehouse. For example, in a contact center an agent may handle inbound calls from one system and outbound calls from another system, with different identities on each system. Data warehouses commonly process each data source independently, performing data correlation across sources at a later time.
Some data models specify a behavior known as a type 2 slowly changing dimension. A type 2 dimension tracks the history of changes to an entity over time. When an attribute of an entity is changed, such as when a contact center agent changes their skill set or group membership, a new surrogate key for that entity is generated, and a new row inserted into the database. Fact data associated with the entity can now be tracked separately for activities that occurred before versus after the change by referencing the appropriate surrogate key.
Business intelligence software, such as sold under the tradename COGNOS 8 provided by Cognos, is an example of a data warehouse. Using web-based tools, e.g. Cognos “Report Studio”, business intelligence software can provide “drag and drop” report creation based on selected data stored in a database. This technology relies on proprietary query engines to construct appropriate Structure Query Language (SQL) queries based on descriptive information in a “metadata model” created e.g. through the Cognos “Framework Manager” tool. Instead of mere schema definition, the metadata model defines all the transformations and business rules needed to cook the raw data into the final report metrics.
Business intelligence software is used in Avaya IQ™, which is an example of a data warehouse tailored for contact center data collection and reporting. Avaya IQ™ has a number of differing layers or components. A first component, referred to as “Tables”, is the database fact and dimension tables containing the collected data. A second component, referred to as “Views”, is a set of database views to enable access to the data in the Tables. A third component, referred to herein as “Reporting Model”, provides a schema definition and defines the transformations and business rules needed to convert the data into the final reports. This third component is also referred to in COGNOS 8 as the aforementioned metadata model. A fourth component, referred to as “Reports”, provides report specifications for the final reports.
Business intelligence software generally provides only limited database dependency information to an unsophisticated user. In COGNOS 8, for example, one performs forward tracing, from a given object to other objects that reference it in their defining expressions, using a feature “Find Report Dependencies”. This feature allows the user to select any object (or collection of objects) in the reporting model and find the list of reports that depend on the object. But the definition of “depend” is limited to those reports that explicitly and directly reference the object in question, so it provides the correct answer only for those few objects that include the thin interface layer (presentation layer) of the reporting model. It does not reveal indirect (chained) dependencies at all. Attempting to use this feature on the vast majority of internal objects in the reporting model (including those at the lowest layer corresponding to items in the database) can give a false impression that no reports depend upon such objects so those objects can be safely deleted from the model. Even for objects in the interface layer that are used by reports, this feature fails to identify the particular items within the report that reference the object in question. To answer that question, the user must open each individual report using the “Report Studio” tool and check manually the expression for all the data items in all the queries defined for that report. Furthermore, the “Find Report Dependencies” feature does not address dependencies between pairs of objects within the reporting model. The only way, that the reporting model user can determine if and where an object is used elsewhere in the model, is to delete that object and hope to see a warning message listing the dependent objects. But even this technique gives occasional false assurances (in cases involving query items in an object known as a query subject shortcut). There is also another feature, “Analyze Publish Impact”, that allows the author of the reporting model to determine which reports will be affected by an, as yet, unpublished change to the reporting model. This was the precursor feature to “Find Report Dependencies” and suffers from the save short falls, plus the added disadvantage that it requires the user to modify the reporting model to see any results.
Backward tracing, from a given object to the other objects that are referenced in its defining expression, would seem to be straight forward, but it is not. The normal operation of Framework Manager allows a user to select an object from a deeply branched tree of previously defined objects and include its reference as a term in the expression for a new/modified object. Nominally, all the user must do to trace backward to those included objects is examine the saved expression and check for references to any predecessor objects. The problem in the reporting model environment is that object references include only the nearest namespace object without identifying where in the deeply branched tree that namespace is located. There is no index of namespaces that can lead one back to a particular namespace and examine the objects it contains. The user must simply know the overall structure of the deeply branched tree (containing hundreds of namespaces) and do an exhaustive manual search of each tree branch until the desired namespace is found. For the broader problem of tracing from a particular item in a particular report backward to the database, the user must start by opening that report in the Report Studio tool and examining the expression for the item in the report query. Not only is this a time-consuming manual operation but also it simply leads back to the reporting model and the problem described above with reference to the Framework Manager tool. To trace backward to the raw database side of the reporting model, the user must have the author's knowledge of the reporting model structure.
With respect to tracing indirect dependencies based on foreign keys of filters, the Framework Manager tool does define and diagram relationships between objects (similar to foreign key relationships between database tables), but their use is limited to the heuristic rules embedded in the proprietary query engine software that generates actual Structured Query Language (SQL) queries from particular report specifications. Following such relationships is important to identifying which foreign key column in a database fact table determines the choice of rows displayed from a dimension table. Highly skilled authors of reporting models have sufficient sophistication to second guess how the query engine is likely to infer such indirect dependencies, but the tools do not reveal how specific indirect dependencies are established. Part of the difficulty is that this determination cannot be made from the reporting model alone. It requires the context of a particular query from a particular report to estimate how such dependencies are established. The Report Studio feature allows the user to examine a prototype of the SQL code that would be generated on behalf of a particular report query. Such queries may contain hundreds of lines of SQL code that only a database expert with great patience could decipher to trace indirect dependencies. This is not a practical way for tracing indirect dependencies.
There remains a need for quality, clarity, verifiability, and maintainability. Reporting models can be enormous and complex in comparison to the data model. In view of the complexity, the reports can be worthless if the data they produce cannot be understood and trusted. Pertinent questions to be understood include: (i) what report values, if any, derive from a particular item in the database (e.g., in case the database is in error or to know how it is manifested for testing); (ii) what database items contribute to a particular value in a report (e.g., to isolate the problem in case the report value is in error); (iii) how does a particular report item derive from database values and what is the formula (e.g., to document the report verify the business rules or instill customer confidence); (iv) even if a particular database item is not in an existing report, is it available for inclusion in future reports (e.g., are reportability and customization requirements met); and (v) when a reporting model is being used, how does an object in the reporting model trace forward toward reports or back toward the database (e.g., is this object needed). In short, database reporting applications require transparency and traceability in both directions between the database and the reports. It is therefore desirable to provide an interface permitting users of a wide variety of differing levels of technical expertise to understand what data is produced for reporting and how that data relates back to the raw data in the database.
Microsoft Access 2007 provides relevant features, but outside of the business intelligence arena. This product provides a feature, known as “Object Dependencies pane”, which allows the user to see both “Objects that depend on me” and “Objects that I depend on”. It can determine what report values, if any, derive from a particular item in the database and what database items contribute to a particular value in a report but the approach is limited in the depth of dependencies that can be displayed and is specific to the Microsoft Access environment where reports and databases are part of the same proprietary package. It therefore does not address the current problems in the business intelligence domain due to its narrow focus and scaling limitations (e.g., it is unable to do end-to-end dependencies for large or complex systems due to depth limitations).